A portion of the disclosure of this patent document contains material to which a claim of copyright protection is made. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure as it appears in the Patent and Trademark Office patent file or records, but reserves all other rights whatsoever.
1. Field of the Invention
The present invention relates to graphical programming, and in particular to a system and method for executing a portion or all of a graphical program in an embedded system, wherein a user interface portion of the graphical programming system optionally also executes on the host CPU.
2. Description of the Related Art
Traditionally, high level text-based programming languages have been used by programmers in writing applications programs. Many different high level programming languages exist, including BASIC, C, FORTRAN, Pascal, COBOL, ADA, APL, etc. Programs written in these high level languages are translated to the machine language level by translators known as compilers. The high level programming languages in this level, as well as the assembly language level, are referred to as text-based programming environments.
Increasingly computers are required to be used and programmed by those who are not highly trained in computer programming techniques. When traditional text-based programming environments are used, the user""s programming skills and ability to interact with the computer system often become a limiting factor in the achievement of optimal utilization of the computer system.
There are numerous subtle complexities which a user must master before he can efficiently program a computer system in a text-based environment. The task of programming a computer system to model a process often is further complicated by the fact that a sequence of mathematical formulas, mathematical steps or other procedures customarily used to conceptually model a process often does not closely correspond to the traditional text-based programming techniques used to program a computer system to model such a process. In other words, the requirement that a user program in a text-based programming environment places a level of abstraction between the user""s conceptualization of the solution and the implementation of a method that accomplishes this solution in a computer program. Thus, a user often must substantially master different skills in order to both conceptually model a system and then to program a computer to model that system. Since a user often is not fully proficient in techniques for programming a computer system in a text-based environment to implement his model, the efficiency with which the computer system can be utilized to perform such modeling often is reduced.
Examples of fields in which computer systems are employed to model and/or control physical systems are the fields of instrumentation, process control, and industrial automation. Computer modeling or control of devices such as instruments or industrial automation hardware has become increasingly desirable in view of the increasing complexity and variety of instruments and devices available for use. However, due to the wide variety of possible testing/control situations and environments, and also the wide array of instruments or devices available, it is often necessary for a user to develop a program to control a desired system. As discussed above, computer programs used to control such systems had to be written in conventional text-based programming languages such as, for example, assembly language, C, FORTRAN, BASIC, or Pascal. Traditional users of these systems, however, often were not highly trained in programming techniques and, in addition, traditional text-based programming languages were not sufficiently intuitive to allow users to use these languages without training. Therefore, implementation of such systems frequently required the involvement of a programmer to write software for control and analysis of instrumentation or industrial automation data. Thus, development and maintenance of the software elements in these systems often proved to be difficult.
U.S. Pat. No. 4,901,221 to Kodosky et al discloses a graphical system and method for modeling a process, i.e. a graphical programming environment which enables a user to easily and intuitively model a process. The graphical programming environment disclosed in Kodosky et al can be considered the highest and most intuitive way in which to interact with a computer. A graphically based programming environment can be represented at level above text-based high level programming languages such as C, Pascal, etc. The method disclosed in Kodosky et al allows a user to construct a diagram using a block diagram editor, such that the diagram created graphically displays a procedure or method for accomplishing a certain result, such as manipulating one or more input variables to produce one or more output variables. In response to the user constructing a data flow diagram or graphical program using the block diagram editor, machine language instructions are automatically constructed which characterize an execution procedure which corresponds to the displayed procedure. Therefore, a user can create a computer program solely by using a graphically based programming environment. This graphically based programming environment may be used for creating virtual instrumentation systems, industrial automation systems and modeling processes, as well as for any type of general programming.
Therefore, Kodosky et al teaches a graphical programming environment wherein a user places or manipulates icons in a block diagram using a block diagram editor to create a data flow xe2x80x9cprogram.xe2x80x9d A graphical program for controlling or modeling devices, such as instruments, processes or industrial automation hardware, is referred to as a virtual instrument (VI). In creating a virtual instrument, a user preferably creates a front panel or user interface panel. The front panel includes various front panel objects, such as controls or indicators that represent the respective input and output that will be used by the graphical program or VI, and may include other icons which represent devices being controlled. When the controls and indicators are created in the front panel, corresponding icons or terminals are automatically created in the block diagram by the block diagram editor. Alternatively, the user can first place terminal icons in the block diagram which cause the display of corresponding front panel objects in the front panel. The user then chooses various functions that accomplish his desired result, connecting the corresponding function icons between the terminals of the respective controls and indicators. In other words, the user creates a data flow program, referred to as a block diagram, representing the graphical data flow which accomplishes his desired function. This is done by wiring up the various function icons between the control icons and indicator icons. The manipulation and organization of icons in turn produces machine language that accomplishes the desired method or process as shown in the block diagram.
A user inputs data to a virtual instrument using front panel controls. This input data propagates through the data flow block diagram or graphical program and appears as changes on the output indicators. In an instrumentation application, the front panel can be analogized to the front panel of an instrument. In an industrial automation application the front panel can be analogized to the MMI (Man Machine Interface) of a device. The user adjusts the controls on the front panel to affect the input and views the output on the respective indicators.
Thus, graphical programming has become a powerful tool available to programmers. Graphical programming environments such as the National Instruments LabVIEW product have become very popular. Tools such as LabVIEW have greatly increased the productivity of programmers, and increasing numbers of programmers are using graphical programming environments to develop their software applications. In particular, graphical programming tools are being used for test and measurement, data acquisition, process control, man machine interface (MMI), and supervisory control and data acquisition (SCADA) applications, among others.
In many instrumentation or industrial automation applications, it is necessary to guarantee real-time performance and/or more deterministic behavior for proper operation. However, current computer operating systems generally cannot guarantee real-time or deterministic performance. This is primarily due to various overhead issues, such as context switches, driver calls, disk caching, user I/O and interrupts, which limit the operating system""s ability to guarantee real-time performance. Therefore, it would be desirable to provide a programmable environment which can guarantee real-time performance. It is further desirable to provide the user the maximum amount of flexibility to create his/her own real-time applications and/or define his/her own instrument real-time functionality using a high level graphical programming environment.
In many instrumentation or industrial automation applications, it is necessary to guarantee real-time performance and/or more deterministic behavior for proper operation. However, most desktop computer operating systems (e.g. Windows 95) generally cannot guarantee real-time or deterministic performance. This is primarily due to the fact that desktop operating systems (specifically, its scheduler) are designed for high throughput at the expense of determinism. This is also due to various overhead issues, such as context switches, driver calls, disk caching, user I/O and interrupts, which limit the operating system""s ability to guarantee real-time performance. Therefore, it would be desirable to provide a programmable environment which can guarantee real-time performance. It is further desirable to provide the user the maximum amount of flexibility to create his/her own real-time applications and/or define his/her own instrument real-time functionality using a high level graphical programming environment.
The present invention comprises a computer-based virtual instrumentation system, herein graphical programs created using the computer system can be downloaded to an embedded system for execution in a real-time or deterministic manner. The present invention thus provides a method for automatically generating an embedded application in response to a graphical program created by a user. This provides the user the ability to develop or define instrument functionality using graphical programming techniques, while enabling the resulting program to operate in an embedded real-time system.
The preferred embodiment of the invention comprises a general purpose host computer system which includes a CPU and memory, and an embedded system or device coupled to the host computer system which also includes a CPU and memory, referred to as an embedded CPU and embedded memory. The embedded memory stores a real-time operating system kernel which provides basic OS services. The embedded system also includes a graphical program execution engine, referred to as embedded LabVIEW, which enables the embedded system to execute the graphical program.
In one embodiment, the embedded system is an interface card or device such as an Intelligent DAQ card or VXI controller interface card coupled to(or plugged in to) the host computer. In this embodiment, the embedded memory further includes a shared memory portion used for bi-directional communication between the host computer and the embedded system. In an alternate embodiment, the embedded system comprises an instrument or device connected to the computer, such as through a network connection. It is noted that the instrument or device comprising the embedded system can take any of various forms, as desired.
The host computer system includes a host graphical programming system, e.g., host LabVIEW, which is used to develop a graphical program. The host LabVIEW also executes code to display the front panel of a graphical program whose block diagram is executing on the embedded system. The host computer system also includes software according to the present invention which is operable to download software into the embedded system to configure or initialize the embedded system.
In one embodiment the embedded system has non-volatile storage media, and at power up the embedded system initializes and configures itself with a real time kernel and an embedded graphical programming system. In alternative embodiment where the embedded system does not have non-volatile boot media for storing an operating system and the embedded graphical programming system, the embedded system receives OS and programs from the host computer. In this case, the embedded system receives it OS and programs from the host computer. Since the operating system and application programs typically reside in a non-volatile media, such as a hard drive, and a computer system typically xe2x80x98bootsxe2x80x99 the operating system from the hard drive, its absence means that an alternative method of booting needs to present.
When the embedded system boots up, the embedded system executes the BIOS code in the read-only memory (ROM), as is typical in any computer system. The BIOS code then executes a BIOS extension program present in memory which requests the operating system kernel from the host computer system. Therefore, the host computer first loads a kernel or basic operating system onto the embedded system. The host computer also transfers one or more other loader applications. As a result, an embedded graphical programming system and various configuration information are then loaded onto the embedded system. In the preferred embodiment, the embedded graphical programming system is embedded LabVIEW. Various software drivers are then loaded onto the embedded system. These components are loaded onto the embedded system using the shared memory and using a shared memory protocol. Thus, once the embedded system is initialized, the embedded system includes a kernel, an embedded graphical programming execution system, e.g., embedded LabVIEW, and any necessary device drivers.
After the system has been configured, the user first creates a graphical program on the host computer system using the host LabVIEW, which includes arranging on the screen a plurality of nodes comprising the graphical program. The host computer then compiles the graphical program to produce a compiled graphical program, depending on the selected target. The user also preferably selects the execution engine for the graphical program, i.e. whether the program will run on the host computer or on the embedded system. If the user has selected the execution engine in the embedded system, the host computer downloads the relevant part of the compiled graphical program to the device through a front panel protocol. The device then executes the compiled graphical program. This includes executing the execution engine to execute the compiled graphical program, as well as executing the OS kernel for basic OS services. Due to the use of a real-time operating system and reduced OS overhead, the embedded system or device executes the compiled graphical program in a deterministic manner.
The graphical program includes a graphical diagram and a graphical front panel. The graphical front panel is usable for providing/displaying input/output to/from the compiled graphical program executing on the device. During execution of a graphical program in the embedded system, the block diagram portion executes in the embedded system, and the host CPU executes front panel display code to display on the screen the graphical front panel of the graphical program. The embedded system and the host computer exchange data using a front panel protocol to enable this operation. Thus, when the device executing the compiled graphical program generates output data for display in the front panel of the graphical program, the output data is transferred to the host computer system, and the host computer system displays the output data in the graphical front panel of the graphical program. In a similar manner, when the user provides input to the graphical program via the graphical front panel, the host computer system displays the input data in the graphical front panel of the graphical program and transfers the input data to the embedded system so that the device can utilize the user input during execution of the compiled graphical program.
The present invention also includes improved debugging support for graphical programs executing on the embedded system. According to the present invention, the user can debug a graphical program executing on embedded LabVIEW utilizing the block diagram of the graphical program displayed on the display screen by the host LabVIEW.
The host LabVIEW and embedded LabVIEW exchange information to enable the user to view debugging information, such as execution highlighting and probe information, on the display screen for a graphical program executing on the embedded system. This provides greatly simplified debugging for embedded graphical programs.
The host graphical programming system or host LabVIEW thus provides the user interface for graphical programs executing on the embedded system. The host LabVIEW thus essentially acts as the front panel xe2x80x9cbrowserxe2x80x9d for embedded LabVIEW applications. The host LabVIEW can also act as an independent application communicating with embedded LabVIEW through the shared memory and/or network. The host graphical programming system further provides a seamless environment in which the user can develop an embedded application using high level graphical programming techniques.